Ââú Ýøø Blockinó Úöö¬ Blockin Blockinøøóòò Ò Óúöúúúû

Web applets have popularized the idea of downloading and exe uting untrusted ompiled ode on the personal omputer running the Web browser, without user's approval or intervention. Obviously, this raises major se urity issues: without appropriate se urity measures, a mali ious applet ould mount a variety of atta ks against the lo al omputer, su h as destroying data (e.g. reformatting the disk), modifying sensitive data (e.g. registering a bank transfer via the Qui ken home-banking software [4℄), divulging personal information over the network, or modifying other programs (Trojan atta ks). To make things worse, the applet model is now being transferred to highse urity embedded devi es su h as smart ards: the Java Card ar hite ture [5℄ allows for post-issuan e downloading of applets on smart ards in sensitive appli ation areas su h as payment and mobile telephony. This raises the stake enormously: a se urity hole that allows a mali ious applet to rash Windows is perhaps tolerable, but is ertainly not a eptable if it allows the applet to perform non-authorized redit ard transa tions. The solution put forward by the Java programming environment is to exeute the applets in a soalled \sandbox", whi h is an insulation layer preventing dire t a ess to the hardware resour es and implementing a suitable a ess ontrol poli y [8, 32, 16℄. The se urity of the sandbox model relies on the following three omponents: